<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
    <title>Reasons to prefer logback</title>
    <link rel="stylesheet" type="text/css" href="css/common.css" />
    <link rel="stylesheet" type="text/css" href="css/screen.css" media="screen" />
    <link rel="stylesheet" type="text/css" href="css/_print.css" media="print" />

  </head>
  <body onload="decorate();">
    <script type="text/javascript">prefix='';</script>
    <script src="templates/header.js" type="text/javascript"></script>
    <script type="text/javascript" src="js/jquery-min.js"></script>
    <script type="text/javascript" src="js/decorator.js"></script>
    <div id="left">
      <noscript>Please turn on Javascript to view this menu</noscript>
      <script src="templates/left.js" type="text/javascript"></script>
    </div>
    <div id="right">
      <script src="templates/right.js" type="text/javascript"></script>
    </div>

    <div id="content">
		
		<h2>Reasons to prefer logback over log4j</h2>

    <p>Logback brings a very large number of improvements over log4j,
    big and small. They are too many to enumerate exhaustively.
    Nevertheless, here is a non-exhaustive list of reasons for
    switching to logback from log4j. Keep in mind that logback is
    conceptually very similar to log4j as both projects were founded
    by the same developer. If you are already familiar with log4j, you
    will quickly feel at home using logback. If you like log4j, you
    will probably love logback.</p>


    <h3 class="doAnchor" name="fasterImpl">Faster implementation</h3>

    <p>Based on our previous work on log4j, logback internals have
    been re-written to perform about ten times faster on certain
    critical execution paths. Not only are logback components faster,
    they have a smaller memory footprint as well.</p>

    <h3 class="doAnchor" name="tdd">Extensive battery of tests</h3>

    <p>Logback comes with a very extensive battery of tests developed
    over the course of several years and untold hours of work. While
    log4j is also tested, logback takes testing to a completely
    different level. In our opinion, this is the single most important
    reason to prefer logback over log4j.  You want your logging
    framework to be rock solid and dependable even under adverse
    conditions.
    </p>
    
    <h3 class="doAnchor" name="slf4j">logback-classic speaks SLF4J
    natively</h3>

    <p>Since the <code>Logger</code> class in logback-classic
    implements the SLF4J API natively, you incur zero overhead when
    invoking an SLF4J logger with logback-classic as the underlying
    implementation. Moreover, since logback-classic strongly
    encourages the use of SLF4J as its client API, if you need to
    switch to log4j or to j.u.l., you can do so by replacing one jar
    file with another. You will not need to touch your code logging
    via the SLF4J API. This can drastically reduce the work involved
    in switching logging frameworks.
    </p>
    
    <h3 class="doAnchor" name="docs">Extensive documentation</h3>
    
    <p>Logback ships with detailed and constantly updated
    documentation.</p>

    <h3 class="doAnchor" name="DSL">Configuration files in XML or
    Groovy</h3>

    <p>The traditional way of configuring logback is via an XML
    file. Most of the examples in the documentation use this XML
    syntax. However, as of logback version 0.9.22, <a
    href="manual/groovy.html">configuration files written in
    Groovy</a> are also supported. Compared to XML, Groovy-style
    configuration is more intuitive, consistent and has a shorter
    syntax.
    </p>

    <p>
    There is also a <a
    href="http://logback.qos.ch/translator/asGroovy.html">tool to
    automatically migrate your logback.xml files to
    logback.groovy</a>.
    </p>

    <h3 class="doAnchor" name="autoScan">Automatic reloading of
    configuration files</h3>

    <p>Logback-classic can <a
    href="manual/configuration.html#autoScan">automatically reload its
    configuration file upon modification</a>. The scanning process is
    fast, contention-free, and dynamically scales to millions of
    invocations per second spread over hundreds of threads. It also
    plays well within application servers and more generally within
    the JEE environment as it does <em>not</em> involve the creation
    of a separate thread for scanning.
   </p>

    <h3 class="doAnchor" name="grace">Graceful recovery from I/O
    failures</h3>

    <p>Logback's <code>FileAppender</code> and all its sub-classes,
    including <code>RollingFileAppender</code>, can gracefully recover
    from I/O failures. Thus, if a file server fails temporarily, you
    no longer need to restart your application just to get logging
    working again. As soon as the file server comes back up, the
    relevant logback appender will transparently and quickly recover
    from the previous error condition.
    </p>
    
    <h3 class="doAnchor" name="maxHistory">Automatic removal of old
    log archives</h3>

    <p>By setting the <span class="option">maxHistory</span> property
    of <a
    href="manual/appenders.html#TimeBasedRollingPolicy">TimeBasedRollingPolicy</a>
    or <a
    href="manual/appenders.html#SizeAndTimeBasedFNATP">SizeAndTimeBasedFNATP</a>,
    you can control the maximum number of archived files. If your
    rolling policy calls for monthly rollover and you wish to keep one
    year's worth of logs, simply set the <span
    class="option">maxHistory</span> property to 12. Archived log
    files older than 12 months will be automatically removed.
    </p>

    <h3 class="doAnchor" name="compression">Automatic compression of
    archived log files</h3>

    <p><a
    href="manual/appenders.html#RollingFileAppender">RollingFileAppender</a>
    can automatically compress archived log files during
    rollover. Compression always occurs asynchronously so that even
    for large log files, your application is not blocked for the
    duration of the compression.
    </p>

    <h3 class="doAnchor" name="prudent">Prudent mode</h3>

    <p>In <a href="manual/appenders.html#prudent">prudent mode</a>,
    multiple <code>FileAppender</code> instances running on multiple
    JVMs can safely write to the same log file. With certain
    limitations, prudent mode extends to
    <code>RollingFileAppender</code>.
    </p>

    <h3 class="doAnchor" name="lilith">Lilith</h3>

    <p><a href="http://lilith.huxhorn.de/">Lilith</a> is a logging and
    access event viewer for logback. It is comparable to log4j's
    chainsaw, except that Lilith is designed to handle large amounts of
    logging data without flinching.</p>
  
    <h3 class="doAnchor" name="conditional">Conditional processing of
    configuration files</h3>

    <p>Developers often need to juggle between several logback
    configuration files targeting different environments such as
    development, testing and production. These configuration files
    have substantial parts in common, differing only in a few
    places. To avoid duplication, logback supports <a
    href="manual/configuration.html#conditional">conditional
    processing of configuration files</a> with the help of
    <code>&lt;if></code>, <code>&lt;then></code> and
    <code>&lt;else></code> elements so that a single configuration
    file can adequately target several environments.
    </p>


    <h3 class="doAnchor" name="filters">Filters</h3>

    <p>Logback comes with a wide array of <a
    href="manual/filters.html">filtering capabilities</a> going much
    further than what log4j has to offer. For example, let's assume
    that you have a business-critical application deployed on a
    production server.  Given the large volume of transactions
    processed, logging level is set to WARN so that only warnings and
    errors are logged. Now imagine that you are confronted with a bug
    that can be reproduced on the production system but remains
    elusive on the test platform due to unspecified differences
    between those two environments (production/testing).
    </p>

    <p>With log4j, your only choice is to lower the logging level to
    DEBUG on the production system in an attempt to identify the
    problem. Unfortunately, this will generate large volume of logging
    data, making analysis difficult. More importantly, extensive
    logging can impact the performance of your application on the
    production system.</p>

    <p>With logback, you have the option of keeping logging at the
    WARN level for all users except for the one user, say Alice, who
    is responsible for identifying the problem. When Alice is logged
    on, she will be logging at level DEBUG while other users can
    continue to log at the WARN level. This feat can be accomplished
    by adding 4 lines of XML to your configuration file. Search for
    <code>MDCFilter</code> in the <a
    href="manual/filters.html#TurboFilter">relevant section</a> of the
    manual.
    </p>
    

    <h3 class="doAnchor" name="sift">SiftingAppender</h3>
    
    <p><a
    href="manual/appenders.html#SiftingAppender">SiftingAppender</a>
    is an amazingly versatile appender. It can be used to separate (or
    sift) logging according to <b>any</b> given runtime attribute. For
    example, <code>SiftingAppender</code> can separate logging events
    according to user sessions, so that the logs generated by each
    user go into distinct log files, one log file per user.
    </p>
    
    <h3 class="doAnchor" name="packagingData">Stack traces with
    packaging data</h3>

    <p>When logback prints an exception, the stack trace will include
    packaging data. Here is a sample stack trace generated by the <a
    href="demo.html">logback-demo</a> web-application.</p>

    <pre>14:28:48.835 [btpool0-7] INFO  c.q.l.demo.prime.PrimeAction - 99 is not a valid value
java.lang.Exception: 99 is invalid
  at ch.qos.logback.demo.prime.PrimeAction.execute(PrimeAction.java:28) [classes/:na]
  at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431) [struts-1.2.9.jar:1.2.9]
  at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236) [struts-1.2.9.jar:1.2.9]
  at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432) [struts-1.2.9.jar:1.2.9]
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) [servlet-api-2.5-6.1.12.jar:6.1.12]
  at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:502) [jetty-6.1.12.jar:6.1.12]
  at ch.qos.logback.demo.UserServletFilter.doFilter(UserServletFilter.java:44) [classes/:na]
  at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1115) [jetty-6.1.12.jar:6.1.12]
  at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:361) [jetty-6.1.12.jar:6.1.12]
  at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:417) [jetty-6.1.12.jar:6.1.12]
  at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) [jetty-6.1.12.jar:6.1.12]</pre>

    <p>From the above, you can recognize that the application is using
    Struts version 1.2.9 and was deployed under jetty version
    6.1.12. Thus, stack traces will quickly inform the reader about
    the classes intervening in the exception but also the package and
    package versions they belong to. When your customers send you a
    stack trace, as a developer you will no longer need to ask them
    to send you information about the versions of packages they are
    using. The information will be part of the stack trace. See <a
    href="manual/layouts.html#xThrowable">"%xThrowable" conversion
    word</a> for details.
    </p>

    <p>This feature can be quite helpful to the point that some users
    mistakenly consider it a <a
    href="http://www.jetbrains.net/devnet/message/5259058">feature of
    their IDE</a>.
    </p>

    <h3 class="doAnchor" name="logbackAccess">Logback-access,
    i.e. HTTP-access logging with brains, is an integral part of
    logback</h3>

    <p>Last but not least, the logback-access module, part of the
    logback distribution, integrates with Servlet containers such as
    Jetty or Tomcat to provide rich and powerful HTTP-access log
    functionality. Since logback-access was part of the initial
    design, all the logback-classic features you love are
    available in logback-access as well.</p>

    <h3 class="doAnchor" name="inSummary">In summary</h3>

    <p>We have listed a number of reasons for preferring logback over
    log4j. Given that logback builds upon on our previous work on
    log4j, simply put, logback is just a better log4j.</p>

    <script src="templates/footer.js" type="text/javascript"></script>	   
    </div>

  </body>
</html>
